Content providers, such as those that stream video content to client subscribers, provide their clients with selection data on an interactive user interface. The selection data is obtained from a data service, and typically includes user interface elements such as menus and icons/tiles representing the available content, e.g., movies and television shows, with which client users can interact to select content for playing.
In a relatively large data service, in order to keep up with a large number of client requests, the data is cached when data is retrieved by the data service. This allows subsequent client requests for an already retrieved data item to be satisfied from a cache rather than from underlying (e.g., physical) data store level of databases and/or other backing data sources of the data service.
However, conventional caching is problematic when program content and its associated selection data needs to be protected from early viewing. If a future show that has not yet been officially released to the public accidentally becomes available, even temporarily, some users can view the show, possibly copy and disseminate it and so on, while other users will be frustrated because they will hear of the release but not be able to view the content until the appropriate time. Similarly, even if the viewable content itself is not available, a user who sees a selection icon/tile for a show that is blocked will be frustrated upon interacting in an attempt to view it.
Thus, at the moment a show becomes available for viewing, the set of available content changes, whereby a spike in the number of client requests occurs; these requests need to be handled below the data caching level. When there is a spike in the number of requests, the data service may fail to keep up. To avoid failing, a typical solution is to add capacity at a level below the caching level, e.g., add larger and/or more data stores/databases operating in parallel. However, adding such additional capacity is expensive.